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ROUTING DATA < t 

The present invention relates to routing data. 

It is known to link video and audio devices in a studio together using a switching 
device, typically a cross point switch. The present inventors have identified the need for a 
system which links audio and video devices in a studio by a switched local, area network, for 
example an Ethernet, operating with a known protocol for example with Internet Protocol 
(IP). However most if not all current video and audio equipment used in studios is not 
equipped to operate with such a switched network operating according to such a protocol. 

The audio and video devices used in a studio include cameras, editors, audio mixers, 
and VTRs amongst other examples. Some devices receive and/or produce both audio and 
video data and some, require control data for controlling them. For example VTRs require 
control data for controlling functions such as play, stop, pause, jog, etc. 

It is thus desired to provide a network interface for coupling a video and audio 
devices to a switched network and which can receive a variety of types of data from the 
network and provide the variety of types of data to the devices. 

According to one aspect of the present invention, there is provided a network 
interface connectable to a packet-based data network on which a plurality of different types 
of payload data are distinguished by network-based packet header data; 

the network interface comprising: 

a plurality of data handling nodes; and 

a routing arrangement responsive to a packet identifier for routing data packets 
between the data handling nodes; 
in which: 

one of the data handling nodes is a network processor for receiving data packets from 
and transmitting data packets to the packet-based network; the network processor being 
operable: 

a) in the case of a data packet received from the data network, to detect the type of 
payload data from the network-based packet header data; to remove the network-based 
packet header data from the packet; and to associate with the packet an identifier which 
specifies a route across the routing arrangement to a target data handling node and a data 
handling operation to be carried out by the target data handling node; and 

b) in the case of a data packet received from another data handling node and having 
an associated packet identifier, to detect the type of payload data from the packet identifier; 
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removing the packet identifier; applying network-based packet header data in dependence on 
the packet identifier; and launching the data packet onto the network. 

Further respective aspects and features of the invention are defined in the appended 

claims. 

Embodiments of the invention will now be described, by way of example only, with 
reference to the accompanying drawings in which: 

Figure 1 is a schematic block diagram of a network in a studio; 

Figure 2 is a schematic simplified diagram of the network showing data flows across 
the network; 

Figure 3 A is a schematic diagram of the format of an audio or video packet used in 
the network; 

Figure 3B is a schematic diagram of the format of an AVSCP or CNMCP packet 
used in the network; 

Figure 3C schematically illustrates a unicast data packet; 

Figure 4 is a schematic block diagram of a network interface of the network of 
Figurel; 

Figure 5A is a schematic diagram of the format of an data packet used in the network 
interface; 

Figure 5B is a schematic example of current flow assignment; 
Figures 5C schematically illustrates data flow in an ENIC; 

Figures 6A and 6B schematically illustrate a packetiser/depacketiser switch of the 
network interface; 

Figure 7 is a schematic block diagram of an illustrative small network for explaining 
a mode of operation of the network; and 

Figure 8 is a schematic block diagram of a proxy generator of the network interface; 

Figure 9 is a schematic diagram of one example of the display of a Graphical User 
Interface (GUI); and 

Figure 10 is a schematic diagram of another example of the display of a Graphical 
User Interface (GUI); 

Figure 11 is a schematic diagram of an example of a graphical interface for 
illustrating the configuration of the network; 

Figure 12 is a schematic diagram of an example of a graphical interface for 
illustrating how data is routed across the network; 
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It should be noted that this example of the network operates as follows: a single 
source device belongs to one and only one multicast group to which it transmits data. A 
destination device receives data from that source device by joining the source device's 
multicast group. That is done by issuing a multicast group join message. The invention is not 
limited to that: other ways of operating are possible. 
Overview of ENICs 

An ENIC is described in more detail in the section below headed ENIC. An ENIC 
allows any source group, for example a camera, and any destination group, for example a 
VTR, which is not designed for use with a multicast network to be used in a multicast 
network. An ENIC is a "dumb" device which can be requested to supply and receive audio, 
video, and control data streams. An ENIC cannot view or initiate any change to the 
configuration of the network. An ENIC may subscribe to one or more multicast groups as 
directed by the network manager 4. 

Each ENIC has an Ethernet address and an IP address. A multicast address and a 
UDP port are used to identify different data streams and in this embodiment a single IP 
address is associated with each ENIC. However, in alternative embodiments multiple IP 
addresses could be associated with a single ENIC. It also has an ENIC identifier ID and port 
Ids for respective ones of the destination devices and source devices of the ENIC. As will be 
described those addresses and IDs and other data are recorded with the network manager 4. 
The source devices and destination devices correspond to respective ones of one or more 
physical inputs and outputs of an ENIC. The source groups and destination groups may have 
"tally text" associated with them. An example of tally text is a name such as "VTR1" which 
may be given to a VTR or a cameraman's name e.g. Jim which may be given to a camera. 
The tally text is recorded at the network manager. All groups connected to the network may 
be named in this way. Source devices may have tally text, termed sub_tally herein, 
associated with them. 

An ENIC acts as a switch which switches data received from the switch 2 to a 
specified physical output of the ENIC and switches data from a specified physical input to 
the switch 2. 

The network, implemented using the switch 2, is asynchronous, but video and audio 
needs synchronous processing. The video and audio devices connected to the network 
operate on serial digital data, for example SDL The ENICs convert serial digital video and 
audio to multicast UDP/IP packets and convert multicast UDP/EP video and audio packets to 
serial digital video and audio. The ENICs also provide synchronous operation over the 
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2. DESTINATION device:: Video, Audio and Status is received from the network by 
joining a multicast group. 

3. CONTROL_SOURCE device: Control commands are generated by an ENIC or 
Client and are transmitted unicast to a CONTROL JDESTINATION. 

4. CONTROL J3ESTINATION device: Receives control commands unicast from a 
CONTROL_SOURCE. 

The client 6 cannot directly access the SOURCE and CONTROL_DESTINATION 
devices. These devices are members of a CONTROL_SOURCEj3ROUP, a structure that 
groups devices that cannot be controlled independently. For example, SDI outputs from a 
VTR are connected to an ENIC for transmission onto the network 2. The SDI input is 
represented as two SOURCE devices (Vo, Ao,) in the network configuration. All of these 
devices are from the same physical device, are jointly controlled and have a common time 
code and stream status, i.e. stop, FF(fast forward), rew (rewind), etc. 

A predetermined set of information is stored in relation to each of the above device 
types, for example a device identifier, a destination IP address associated with the device and 
a UDP port and/or IP address of an ENIC associated with the device. 

A predetermined set of information associated with an ENIC known as an ENIC 
structure is held in a database in the network manager and comprises the Ethernet address 
and DP address of the ENIC. The ENIC structure also maps the associated devices (e.g. 
audio and video streams) to the physical ports on the card and includes any hardware 
limitations that restrict the ideal model described above. When an ENIC starts up it will 
receive information on what devices are connected to its RS422 ports (i.e. VTR, TALLY), 
so that the correct driver can be used. 

Overview of Switching and Routing Client 6. 

There may be one or more clients 6, 61 connected to the network but the following 
description assumes there is only one. The network manager 4 provides the client 6 with 
information specifying the configuration of the network. The client 6 can initiate a 
connection between a source device and a destination device across the network. All requests 
for initiating such changes to the configuration of the network are sent to the network 
manager 4. Control data which does not change the configuration of the network may be 
issued by the client 6 directly to an ENIC and, via ENIC, a group associated with the ENIC. 
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instruction between the ENIC and the switching control server 6 is sent via the AVSCP 
protocol. 

AVSCP has five main functions which are to: 

1) Monitor the operational status of the ENICs; 

2) Discover the configuration of an ENIC; 

3) Stop and start audio and video source transmission; 

4) Direct ENICs and their associated audio and video devices to join multicast groups; and 

5) Set up and tear down paths for conveying control data across the network. 

The network manager 4 should be aware of the operational status of an ENIC 
before it can send any instructions to it. Accordingly the AVSCP requires an ENIC to send 
status messages to the server periodically. The network manager 4 can only control AV 
stream transmission and reception of an ENIC when it is operational. The network manager 
4 can alternatively obtain the current configuration of an ENIC by sending a configuration 
request message to it. The ENIC responds by returning a message specifying the current 
configuration. 

Figure 14 schematically illustrates how AVSCP relates to other functional modules 
in an ENIC network protocol stack. The arrangement of Figure 14 shows identical protocol 
stacks of two different ENICs 1 1 00 A and 1 1 00B and a protocol stack of the network 
manager 1 120. The ENIC protocol stack comprises an AVSCP layer 1 104 that sits on top of 
a UDP/IP/Ethernet layer 1 1 02. Other protocols 1 1 06 may also be implemented at the same 
level of the protocol stack as AVSCP. The AVSCP layer communicates with a higher layer 
comprising ENIC applications via an AVSC_request command and an AVSC_indicate 
command. An uppermost layer of the ENIC protocol stack 1 100A represents a local 
configuration 1 1 1 0 of the network. The network manager protocol stack 1 1 20 is similar to 
the ENIC protocol stack 1 1 00 A in that it comprises an AVSCP layer 1 124 that sits on top of 
a UDP/IP/Ethemet layer 1 122. However, a server applications layer 1 128 sits on top of the 
AVSCP layer 1 124 and communications between these two layers are mediated by the 
AVSC_request command and the AVSC_indicate command. The server applications layer 
1 128 is in communication with a higher layer corresponding to a network configuration 
database 1 130. The AVSCP protocol layer of the ENIC 1 104 may send AVSCP protocol 
messages to the corresponding AVSCP protocol layer 1 124 of the network manager. 

The AVSCPjrequest is a primitive command that is sent from the application layer 
1 108, 1 128 to the AVSCP protocol layer 1 104, 1 124. An application initiates an 
AVSCP_request in order to send an AVSCP message to another AVSCP entity. The AVSCP 
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associated with the ENICs which are connected to the network and data associated with 
source devices and destination devices connected to the network by the ENICs. By sending 
CNMCP messages to the client, the network manager 4 informs the client of the multicast IP 
addresses on which it can receive the proxy video streams, audio streams and status streams. 
The network manager can determine whether sufficient bandwidth is available to service a 
client request and mediates access to network resources accordingly. However, it is also 
possible for the client to join a multicast group directly without requesting access via 
network manager. This may be appropriate where, for example, the client requires only a 
low data-rate connection. 

Alternatively to CNMCP, a known protocol such as Simple Network Management 
Protocol ( SNMP) may be used. The client 6 can cause the network to connect Audio and 
Video streams from source devices specified by the client to destination devices specified by 
the client and to specify control data routing by sending CNMCP or SNMP messages to the 
network manager. 

Audio and Video Data (RTP) 

For sending streams of audio and video data from the sources to the destinations, the 
transport layer is UDP multicast. The audio and video data are carried in Real-Time Protocol 
(RTP) format within a UDP packet. This applies to the audio data, the full resolution video 
and the low resolution proxy video. (See Section Data Format and Figure 3A below for a 
description of the data format). RTP provides functions to support real-time traffic, that is, 
traffic that requires time-sensitive reproduction at the destination application. The services 
provided by RTP include payload type identification (e.g. video traffic), sequence 
numbering, time-stamping and delivery monitoring. RTP supports data transfer to multiple 
destinations via multicast distribution if provided by the underlying network. The RTP 
sequence numbers allow the receiver to reconstruct the original packet sequence. The 
sequence numbers may also be used to determine the proper location of a packet. RTP does 
not provide any mechanism to ensure timely delivery, nor does it provide other Quality of 
Service guarantees. 

When an ENIC receives an AVSCP switch request from the network manager 4, the 
ENIC sends an IGMP join message to the switch 2 to join the multicast group of the data it 
needs to receive. 
Unicast Control Data f UCD) 
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low-order 23 bits of the Ethernet address. Accordingly 5 bits of the multicast group ID are 
not used to form the Ethernet address. As a consequence the mapping between the IP 
multicast address and the Ethernet address is non-unique i.e. 32 different multicast group IDs 
map to the same Ethernet address. 

The UDP header comprises source and destination port numbers, which are typically 
associated with a particular application on a destination device. Note that UDP is redundant 
in the case of multicast messages since in this case the multicast group address identifies the 
stream/content. The audio/video streams are transported using RTP protocol. Forward Error 
Correction (FEC) may be used for certain data streams e.g. full resolution video streams to 
provide a level of protection against data corruption due to network errors. FEC is provided 
using a known RTP payload format that provides for FEC. FEC is a parity-based error 
protection scheme. A known extension to the RTP protocol allows a video scan line number 
to be specified in the RTP payload .header. The RTP header also comprises a field to specify 
whether 8-bit or 10-bit video is present. Although known RTP and RTP/FEC protocol 
formats provide the data packet fields necessary to transport audio and video data over an IP 
network it may also be desired to transmit additional information such as source status and 
source timecode information. For example if the source is a VTR then the timecode as 
stored on the tape should be transferred across the network. The source status information 
might indicate, for example, whether the VTR is currently playing, stopped or in jog/shuttle 
mode. This status information allows a user to operate the VTR from a remote network 
location. Since the timecode data and source status information is required only once per 
field, the information is transported in an RTP packet marked as vertical blanking. To allow 
audio and video resynchronisation. the RTP timecode is based on a 27MHz clock. The 
payload type field contains data indicating the type of payload. i.e. video or audio. The 
payload field contains the video or audio data. The CRC is a cyclic redundancy check 
known in the art. 
AVSCP and CNMCP 

AVSCP and CNMCP messages are carried by a data format as shown in Figure 3B. 
The format comprises in order, an Ethernet header, an IP header which is not a multicast 
header), a UDP or TCP header, the payload, and a CRC field. The Ethernet header comprises 
source and destination Ethernet addresses. The IP header comprises the source ENIC EP 
address and the destination ENIC IP address. UDP is used for AVSCP and TCP is used for 
CNMCP. The payload field contains the AVSCP or CNMCP message. The CRC is a cyclic 
redundancy check known in the art. 
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The packetiser/depacketiser has 3 video inputs 218 for receiving respective SDI 
video streams, 3 audio inputs 220 for receiving respective audio streams. Alternatively, three 
input ports could be provided for receiving combined SDI audio/video streams and the audio 
and video streams could be subsequently separated to form 3 audio and 3 video streams with 
in the ENIC The packetiser/depacketiser 24 has likewise 3 video outputs 222 and 3 audio 
outputs 224. 

The CPU 26 has 3 control data inputs 226 and 3 control data outputs 228. 

The three video inputs 218 are connected to respective ones of three substantially 
real-time proxy video generators 212 which generate the low resolution versions of the video 
streams as will be described below. The outputs of the proxy generators and the inputs 218 
are connected to a packetiser and multiplexer 214, which converts the full resolution serial 
video from the inputs 218 and the proxy video from the proxy generators 212 to packets. The 
packets are supplied to the packet switch 22. The packetiser/depacketiser 24 has a 
depacketiser 216 and demultiplexer for receiving packets representing the video and audio 
channels from the packet switch 22. It depacketises and demultiplexes the video and audio 
into 3 serial video streams and 3 serial audio streams for supply to respective ones of 3 video 
outputs 222 and 3 audio outputs 224. Thus the packetiser/depacketiser 24 provides routing of 
the video and audio received from the packet switch 22 to outputs 222 and 224 and routing 
of the video and audio received from the inputs 218 220 to the switch 22. The 
packetiser/depacketiser 24 also provides synchronisation of the different video and audio 
streams in conjunction with the clock synchronisation circuit 204 and frame alignment of the 
video frames of the different video streams in conjunction with the frame synchronisation 
circuit 205. 

The packet switch 22 provides routing of video, audio and control packets received 
from the network processor 20 in accordance with tags applied to the packets in the network 
processor 20. The network processor 20 generates the tags in accordance with header data in 
the received packets. There are two sorts of tag: a "flow" tag which defines the route through 
the packet switch 22 and a "type" tag which defines the final output to which the packets are 
supplied by the packetiser/depacketiser 24. The video and audio packets are routed to the 
depacketiser 216 and the control packets are routed to the CPU 26. The CPU provides 3 
control data channels 228 here denoted "RS422" because they provide control similar to that 
provided by RS422 in a conventional studio. CPU 26 also receives 3 control data channels 
226. 
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video data payload of Figure 3A. In the case of AVSCP/CNMCP data packets and unicast 
control data packets (see Figures 3B and 3C) the tagged packet payload is the message data. 

The flow data field defines the output of the packet switch 22 (Figure 4) 
corresponding to the target data-handling node for which the tagged packet payload is 
destined. The type data field determines what the target processor does with the data and the 
size data field specifies the payload size. 

Figure 5B schematically illustrates an example of a flow assignment allocation. In 
this example flow 0 corresponds to data that will not be passed to any target processing 
device e.g. untagged data; flows 1 and 4 correspond to video input and output ports 218, 222 
(see Figure 4); flows 2 and 5 correspond to CPU data flows from and to the network; and 
flows 3 and 6 correspond to PCI data flow from and to the network. 

Figure 5C schematically illustrates how video data, PCI data, network data and CPU 
data is mapped to each of the six defined flow paths via multiplexers (MUX) and 
demultiplexers (DEMUX). Each of the data flows of Figure 5B is associated with a FIFO. 
There is no direct means of determining the size or number of packets written to the FIFO 
since this is not necessary. The tags associated with the packets specify the packet size so 
only a "not empty" indication for the FIFO is required by a MUX to perform a read 
operation. The MUX modules are programmable (by external means such as a CPU) such 
that they are sensitive only to particular flows. This enables virtual flow paths to be set up 
across the buffer and packet switch 22 of Figure 4. Similarly, to avoid contention, only a 
single DEMUX module can write into any one data flow. Again, the mapping is 
programmably controlled by externa] means. 

Referring to Figure 6A ; the video section of the packetiser/depacketiser 24 is shown: 
It comprises a demultiplexer 2401 which responds to the "type" data in the tags attached to 
the video packets to feed video packets to three channels V0, VI and V2 denoted by the 
type data. Each channel comprises an RTP/FEC decoder 2402, 2403, 2404 followed by a 
frame store 2405. The RTP decoder 2402 removes the tag from the packet it receives and 
writes the packet into the frame store at the address defined by the RTP packet header, in 
particular the line number data thereof, to create a video frame having the video data in the 
correct order. 

Example of operation 1 
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processing operation. A pure source is a source that supplies to the network for the first 
time. 

The video source device for each camera is a 'pure 5 source. Each camera has a user 
group called "Producer" and the Producer has set the tally tag to be the name of the 
cameraman, i.e. FRED or JIM. There are three other ENICs on the network. The first 
performs a visual effect on the video from 'Camera 1' and is called ENIC_DME since it 
performs digital multi-effects (DME). This ENIC will have two device entries in the 
database, called 'DME In' and 'DME Out'. 'DME In' is a destination device, which has a 
video link to 'DME Out'. 'DME Out' is a source device, which has a video link to 'DME In' 
and transmits onto the network. 'DME Out' also has a tally entry of El (indicating EFFECT 
1). The second ENIC performs a seamless switch between two sources and is called 
ENIC_AB_SWITCH. This ENIC will have three device entries in the database, called 
'Switch A In', 'Switch B In' and 'Switch Out'. 'Switch Out' is a source device that will 
either be linked to 'Switch A In' or 'Switch B In', depending on which video source is 
selected. The third ENIC is called ENIC_AIR and has one device called 'Monitor' (a 
monitor with a tally). 'Monitor is a 'pure' destination device (LINKED = 0) that receives 
video from the AB switch. It also has a tally that displays the METADATA from its source 
device, 'Switch Out'. 

Say that the AB switch is showing channel A and the METADATA of Camera 1 
changes. Maybe ROB replaces FRED. A request will be sent to the Network Manager to 
changed FRED to ROB. The Network Manager will examine each destination Device that is 
subscribed to Camera l's multicast group and update the view of any client that is displaying 
it. If any of these destination devices is a linked device, then it must navigate to the 
corresponding linked source device and update all of its destinations, and so on. In the 
scenario above, 'DME In' is the only destination device and it is linked to 'DME Out'. 
'DME Out's' METADATA (El) is concatenated to ROB to form ROBJE1 and all of its 
destinations must be notified. The only destination device is 'Switch A In'. Since the switch 
is showing channel A, 'Switch A In' is a linked destination device and we must update all 
destinations of its corresponding source device ('Switch Out'). 'Switch Out' only has one 
destination and this is a pure destination 'Monitor'. The tally of 'Monitor' is updated with 
'ROB_El'. Another scenario is when we perform an AB switch. A request will be sent to the 
Network Manager to perform a seamless AB switch between devices 'Switch A In' and 
'Switch B In'. If the network has been configured correctly, as above, then this is allowed. 
Since SRC DEVICE of 'Switch B In' references 'Camera 2', we can navigate to 'Camera 2' 
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either the proxy video stream or the higher-resolution SDI video stream could be assigned to 
different multicast groups. 

In a currently preferred example of the invention, the proxy video comprises 180 
samples x 144 lines (PAL) or 180 samples xl20 lines (NTSC) and 25 or 30 frames per 
5 second, with horizontal and vertical filtering. The number of bits per sample may be 24 bits 
(i.e. 3 colours, each 8 bits) or 16 bits (i.e. 3 colours, each 5 bits). 
Switching and routing client 6 

Referring to Figures 9 and 10, examples of graphical user interfaces (GUI) are 
shown. In this example of the invention, the GUI is provided by the switching and routing 
10 client 6. However the GUI may be provided by the network manager 4 or by both the 
network manager 4 and the switching and routing client 6. The GUI is an interface with 
underlying software which reacts to actions taken by the user using the GUI. 
Data flows 

The GUI displays information about the configuration of the network provided to it 

15 by the network manager 4. That information is provided using the CNMCP protocol as 

discussed above. The GUI also displays proxy video provided by the ENICs using the Real 
Time Transport protocol described above. The proxy video is multicast and to receive it the 
switching and routing client joins the multicast groups of the proxy video streams. The 
routing of data is established using IGMP message commands. The GUI may be used to 

20 initiate control of a controllable group such as a VTR. The switching and routing client 6 

unicasts control data directly to the ENIC associated with the controlled group in response to 
an action taken via GUI. Unicast control data is described above. The switching and routing 
client receives status stream data which is multicast as described above and the client joins 
the multicast group thereof. 

25 When the GUI is used to initiate a routing of video from a source device to a 

destination device, it sends an CNMCP message to the network manager 4. The network 
manager sends an AVSCP message to the ENIC associated with the destination device to 
cause it to join the destination device to the required multicast group. 

The client 6 is able to send IGMP join messages to the network. However, the client 

30 may also self-subscribe to a multicast group for communication of status, audio and proxy 
data streams only. The network manager controls client access to a multicast group 
corresponding to a video stream. The GUI 
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the source device. 

If the client is not permitted to perform this operation then the Network Manager will 
send a CNMCP NAK message to the client in response. Otherwise it will process the request 
as follows. 

The Network Manager will examine the database and determine which multicast IP 
address the video is being transmitted to. An AVSCP Switch message will be created that 
contains this IP address and it is sent to the ENIC, which connects the Monitor. The ENIC 
embedded software sends an IGMP Join message to this IP address and sends an AVSCP 
ACK message back to the Network Manager. The ENIC should now be receiving the desired 
video data and will send it to the SDI output that connects the Monitor. Meanwhile, the 
Network Manager, having received the AVSCP ACK message, will update the routing 
information in the database. The Network Manager sends a CNMCP ACK message back to 
the client to indicate success. 

The GUI of Figure 9 preferably also includes, as shown, two further display areas 
Ml and M2 showing the video displayed on play-out monitors MON 1 and MON2. In this 
example MON2 has a dark border indicating that it shows the video being played out on 
LINE OUT 1 from for example VTR1 . MON 1 which has a lighter border shows the video 
from CAM1 which has been preselected for play-out next. The video maybe selected for 
display in the windows MON1 and MON2 by dragging and dropping proxy video from 
windows Wl to W10 into MON 1 and MON 2. The video to be played out maybe selected 
by clicking on MON1 or MON2. 

The GUI of Figure 9 has an audio control display area AUD. 

The GUI also has virtual controls CI to CI 0 associated with the windows W 1 to 
W10 and controls CM associated with the MON1 and 2 windows. Operation of such a 
control causes the underlying software to send unicast control data UCD across the network 
directly to the source group from which the video in the associated window originates. 
Alternatively, or in addition, CI to CIO can indicate the current status of the relevant device. 

The GUI of Figure 10 differs in minor ways from that of Figure 9. It has proxy video 
display areas Wl to W8, a network management area Al (shown only schematically) 
identical to that of Figure 9, and monitor displays Ml and M2. The GUI of Figure 10 lacks 
the rows of source and destination buttons, but has two buttons Ml and M2 which act, like 
the buttons of Figure 9, as switches. The buttons Ml and M2 select for play-out video 
associated with an associated one of windows Ml and M2. The played out video is displayed 
in a play-out window MP. 
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both DSP 2 and DSP 3. The names of the sources e.g. CAM 1, VTR 1, MIC 1 are derived 
from the tally text. 

Figure 12 schematically illustrates a GUI that provides the user with an overview and 
an interface for displaying to an operator how the data is being routed across the network. 
The GUI comprises a routing review overview panel 121 at the top of the screen and a main 
routing review panel 122 comprising a source sub-panel 123 and a destination sub-panel 
124. The overview routing review panel 121 provides an easily comprehensible overview of 
the relationships between sources and destinations. This is achieved by colour-coded 
highlighting. This panel 121 currently indicates that source CAM1 is connected to 
destinations MON1, MON2, MON3, VTR2 and AUOUT3. By clicking on a given source 
area of the routing review overview panel 121, that source and any destinations associated 
with it are highlighted. The sources sub-panel 124 provides an expanded view of the source 
in which both the source group e.g. CAM1 and the associated device VI or V2 are 
graphically represented. Similarly, the destinations sub-panel provides an expanded view of 
the destination groups. From the highlighted areas in the sources sub-panel 121 and the 
destinations sub-panel 124 it is apparent that CAM1 device VI is connected to devices VI 
and V2 of MON1 for example. The destination sub panel 124 also provides a graphical 
colour coded matrix representation of source-destination connections. 

Figure 13 schematically illustrates a user interface provided on the network manager 
via which a user may manually enter configuration data. When a device is connected to 
the network, the user informs the network manager that this is the case via the user interface. 
The interface comprises an ENIC ID dialog box, a PORT ID dialog box and a TALLY 
TEXT dialog box. The user enters into dialog boxes data required by the manager to 
determine the configuration of the network. The ENIC ID entry is a user-defined identifier 
e.g. ENIC6, the PORT ID entry specifies the ENIC port to which the device has been 
connected and the TALLY TEXT entry specifies the freely assignable label (referred to 
above as tally text) used as a source/destination identifier. The tally text ID is used in 
addition to (rather than as an alternative to) the source and destination identifiers ID 
discussed above. 



References. 

1 5 RTP Payload Format for BT.656 Video Encoding, D. Tynan, (Claddagh Films) RFC2431, 
Oct. 1998. 
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5. A network interface according to claim 4, in which the routing arrangement 
comprises a demultiplexer for demultiplexing different types of packets to different routing 
paths in dependence on the type identifier. 

6. A network interface according to claim 5, in which a respective multiplexer is 
associated with each data handling node, each multiplexer being arranged to receive data 
packets from the routing paths which have that data handling node as a target node. 

7. A network interface according to any one of claims 4 to 6, in which: 
the types of payload data include audio data and video data; and 

one of the data handling nodes is an audio/video processor for extracting audio 
and/or video data from a packet payload and generating an output audio and/or video signal. 

8. A network interface according to claim 7, in which: 

in the case of a data packet received from the data network having an audio or video 
data payload, the network processor is arranged to associate with the packet an action 
identifier which specifies whether the payload comprises audio or video data and a type 
identifier specifying the audio/video processor as the target data handling node; and 

the audio/video processor processes the data packet as audio data or as video data in 
dependence on the action identifier. 

9. A network interface substantially as hereinbefore described with reference to the 
accompanying drawings. 

10. A method of operation of a network interface connectable to a packet-based data 
network on which a plurality of different types of payload data are distinguished by network- 
based packet header data; the network interface comprising a plurality of data handling 
nodes; and a routing arrangement responsive to a packet identifier for routing data packets 
between the data handling nodes; in which one of the data handling nodes is a network 
processor for receiving data packets from and transmitting data packets to the packet-based 
network; the method comprising the steps of: 

a) in the case of a data packet received from the data network, detecting the type of 
payload data from the network-based packet header data; removing the network -based 
packet header data from the packet; and associating with the packet an identifier which 
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ABSTRACT 
ROUTING DATA 

A network interface connectable to a packet-based data network on which a plurality 
of different types of payload data are distinguished by network -based packet header data; 
comprises: 

a plurality of data handling nodes; and 

a routing arrangement responsive to a packet identifier for routing data packets 
between the data handling nodes; 
in which: 

one of the data handling nodes is a network processor for receiving data packets from 
and transmitting data packets to the packet-based network; the network processor being 
operable: 

a) in the case of a data packet received from the data network, to detect the type of 
payload data from the network-based packet header data; to remove the network-based 
packet header data from the packet; and to associate with the packet an identifier which 
specifies a route across the routing arrangement to a target data handling node and a data 
handling operation to be carried out by the target data handling node; and 
b) in the case of a data packet received from another data handling node and having an 
associated packet identifier, to detect the type of payload data from the packet identifier; to 
remove the packet identifier; to apply network-based packet header data in dependence on 
the packet identifier; and to launch the data packet onto the network. 
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Flow 0 (Evaporate) I 



Flow 1 (Net-Video IO) 



Flow 2 (Net-CPU) 



Flow 3 (Net-PCI) 



Flow 4 (Video lO-Net) 



Flow 5 (CPU-Net) 



Flow 6 (PCI-Net) 



Example of the current flow assignment 

FIG 56 
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Example of a packet with a tag 
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